Typically, after a software application is built, the source code, configuration files, and other artefacts are generated, compiled, and packed into load modules. Once these load modules are built, the load modules may be shipped to an execution environment where they are loaded and possibly linked to a processing unit.
FIG. 1 is a flow chart illustrating a typical build process. Source files 110 may be provided or automatically created using a generator 120. A generator 120 may use configuration files 100 to automatically generate source files 110 using, for example, generic frames, classes, prototypes, templates, aspects, or other ontological models. Generator 120 may also include one or more programming tools, such as a template processor or an integrated development environment (“IDE”).
The source files 110 may be compiled by a compiler 130 into object files 140. The compiler 130 may be a computer program, or a set of programs, that transforms source code written in one programming language into another computer language. For example, the compiler 130 may translate source code from a high-level programming language to a lower level language, such as assembly language or machine code.
In a typical build process, as illustrated in FIG. 1, a compiler 130 may translate source files 110 into object files 140. Object files 140 may contain, for example, relocate-able format machine code. Since object files 140 may not be directly executable, they may be inputted into an archiver 150. The archiver 150 may be a linker, or link editor, that takes one or more object files generated by a compiler 130 and combines them into a single executable program, or load module 160. A computer application may comprise several modules 160, and all of the modules are not necessarily contained in a single object file 140. For example, the object files 140 may contain symbols that are resolved by an archiver 150, which links the object files into a unified executable program, or load modules 160. As a result, the load modules 160 may comprise an Executable and Linkable Format (“ELF”) archive, a JAR (Java™ ARchive) or TAR (Tape ARchive) file, a Debian (“DEB”) or RPM package, or other containers.
Once the load modules are built for a software application, the type of the software application may determine how the load modules are sent from the building site to be loaded onto a processing unit. Currently, when sending the load-units to the processing unit, it is often assumed that the new load-units do not interfere with the existing software on the processing unit. Additionally, it is often assumed that the new load module is compatible with underlying software frameworks on the processing units, such as middle-wares and operating systems. In some instances, a new load module may be tested in a sand box on a processing unit. Sand boxes allow a new load module to be tested against the actual processing unit environment without the risk of interfering with the operation of the actual equipment.
FIG. 2 is a flow chart illustrating load modules loaded onto a processing unit. In a typical load process, the worst case is that no checks are performed when the load modules 160 are loaded onto the processing unit 200. In other cases—such as when a package manager, like apt or yum is used—rudimentary dependency checks are performed when new packages are loaded onto a processing unit 200 or existing ones are updated. Packages that violate one or more dependencies may not be loaded.
The above build and load processes, illustrated in FIGS. 1 and 2, may function well in static environments where software changes are relatively infrequent. For example, current processes may be sufficient in a desktop setting or in a small server farm. However, in modern environments, the above build and load processes present problems. For example, in large data-centers and cloud deployments, ordinary containers or package systems are not sufficient. Additionally, since the state changes frequently in data-centers and cloud environments, frequent load module deployments are required. Furthermore, especially in a cloud environment, one must be able to package functioning software and deploy it on dynamically allocated virtual machines.
Complex applications also often stretch over several processing units 200. It is common for applications to span several processing units 200, so installation and upgrade must be coordinated across several processing units 200. For example, software may need to be loaded onto processing units 200 that perform specific tasks, and as a result, different pieces of software must work together when loaded onto the processing unit. Processing units 200 and services may also be shared between users that have different requirements. Additionally, the new software may interfere with existing software, and thereby cause errors and down-time when executed on a processing unit.
Accordingly, there exists a need to overcome the deficiencies of current software build and load processes.